情境- Single Zone HA

HA : Highly Available

• (自動) 在 100 iterations, 1000 ms 為間隔 跑Get access token from API Gateway
• (手動) 使用Kube Dashboard 接續砍2個pod

Result: 5x Success, 4x Failed

為什麼會有失敗的Case?

ChatGPT reply:
在「Single Zone HA」的情境下，出現失敗的原因可能與以下幾個因素有關：

Pod 切換的瞬時影響： 當手動砍掉兩個 Pod 時，即使系統是高度可用 (HA)，Kubernetes 仍需要時間調度新的 Pod。這可能會導致短暫的服務中斷，特別是在這個過程中某些請求無法被及時處理，導致失敗。

負載均衡器的延遲： 在 Kubernetes 中，負載均衡器需要時間將流量重新分配到健康的 Pod。如果負載均衡器的反應速度較慢或沒有及時感知到 Pod 被砍掉的情況，可能會繼續將流量分配到已經被刪除的 Pod 上，導致部分請求失敗。

API Gateway 的健康檢查機制： API Gateway 可能需要時間來更新其內部的 Pod 狀態。如果健康檢查機制有延遲，API Gateway 可能仍然會將請求發送到已經被砍掉的 Pod，導致部分請求失敗。

資源限制或性能瓶頸： 如果系統資源（如 CPU、內存）在高負載下受到限制，Pod 切換過程可能會更慢，導致短暫的性能下降或請求超時。

你可以檢查以下幾點來分析具體原因：

查看 Pod 重啟和調度的事件日志。
檢查負載均衡器和 API Gateway 的健康檢查和狀態更新機制。
確認系統資源的使用情況是否在可接受的範圍內。
此外，你可以嘗試縮短 Pod 切換過程中的延遲或使用更短間隔的健康檢查來減少失敗的次數。

個人觀點:
-> 砍得間隔太短，可改成設定3個Pod，砍2個Pod。
總數為2個Pod，全數砍光的操作，或許是導致失敗的原因...

ChatGPT reply:

從你的觀點來看，Pod 被砍光的情況可能會導致服務無法正常運作，特別是當每次縮減或擴展的間隔太短時，更可能引發資源不足或不穩定的狀況。

調整為設定3個Pod，但只砍2個Pod，並保留至少1個Pod存活，可以避免服務全數停擺的風險。這樣的做法有助於確保至少有一個Pod繼續處理請求，降低系統中斷的可能性。這樣的設定應該能夠提升系統的穩定性，特別是在負載變動時，Pod數量不至於瞬間降至0，導致服務中斷。

此外，根據應用程式的需求，調整縮減間隔時間也是提升可靠性的好做法，避免過快的擴展或縮減導致Pod無法順利啟動或停止。

Gemini reply:

Pod 砍掉後系統恢復時間
配置影響： Pod 的自動伸縮配置、服務發現機制以及容器啟動時間等都會影響系統恢復的速度。
資源限制： 如果集群資源有限，砍掉 Pod 後，新的 Pod 可能需要等待資源才能啟動，進一步延長恢復時間。
依賴關係： 如果系統中存在複雜的服務依賴關係，砍掉 Pod 可能會觸發連鎖反應，導致其他服務不可用。
建議：

增加觀察窗口： 在砍掉 Pod 後，增加一段觀察時間，確保系統能夠穩定恢復。
逐步減少 Pod： 逐漸減少 Pod 的數量，觀察系統的反應，以便更精確地定位問題。

對策

設定3個pod，逐步砍Pod在100 iterations 執行期間。
紀錄1pod，長回時間，知道上限，並設定alert rule於prometheus，並使用alertmanager發送alert當上限踩到前。
Alert rule 預期設置: Pod < 2 即觸發。

其他參考

https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#strategy

策略

.spec.strategy 指定用於以新 Pod 取代舊 Pod 的策略。 .spec.strategy.type 可以是「Recreate」或「RollingUpdate」。 “RollingUpdate”是預設值。